With an increase in reliance by system-on-chip (SoC) engineers on re-use in order to minimize design time and reduce risk, the demand for more robust and complicated cores continues to rise. Such robust and complicated cores have to be tested and verified exhaustively to ensure that such cores operate effectively in all possible scenarios, and that a high level of quality is maintained during the test and verification. To this end, there has been an increase in demand for advanced tools and methods for functional verification.
However, the verification of ASIC designs has proven problematic over the years. For example, the overhead required for complete design verification of the infrastructure development and test writing is usually expensive. As such, in the design of many ASICs, the verification activity often lags design activity, and thus, requires verification teams to outman design teams by a significant ratio.
Another problem encountered in design verification is that a design under test (DUT) description is captured in a number of entities such as tests, models, monitors/checkers, and functional coverage assertions. As a result, a small RTL change requires extensive work on the part of the verification engineers. As an example, a small 10-line RTL change often requires changes to the models to accommodate the new behavior associated with the change. Functional coverage assertions need to change as well so as to capture the new behavior. Also, new test/constraints need to be written to capture the new behavior as well. Thus, the small 10-line RTL change has the potential of exploding into a lot of redundant work in the design verification environment in that creating and maintaining all this code requires a significant amount of effort.
Such techniques tend to focus on merely verifying RTL code/design, and fail to use a more robust approach of double-entry verification that can use two independent implementation descriptions, which can then combine to verify the DUT.
To help reduce the amount of time, effort and code required to verify an ASIC, a number of developments have occurred in the past. One such development utilizes “constrained random” test generation and functional coverage to help reduce the effort required to create tests. Because constrained-random verification can automatically generate a large number of test case within the parameters (i.e., constraints) specified by the verification team, constrained-random verification can hit corner cases that neither the design nor verification engineers would have ever anticipated. Without constrained-random stimulus, design bugs lurking in these corners hide until late in the development cycle, or perhaps, are not found at all until customer usage. However, such constrained-random test generation requires a significant investment of time and effort of the verification engineers to set up the verification infrastructure and run the tests. Moreover, although feedback can be used to adjust constraints to achieve functional coverage, a limited amount of coverage can be achieved using constrained-random techniques. Hence, additional tests and development are usually needed to close the gap not accounted for in the functional coverage.
Other known developmental efforts have suggested algorithmic techniques using a rule-based language based on, for example, BNF (i.e., Backus-Naur Form). BNF is a meta-language for describing other computer languages. However, these efforts have limited the use of BNF to merely describing computer language syntax that may then be used to automatically generate parsers using compiler-compiler technology. Similar to the previously discussed shortcomings, such current techniques do not reduce the amount of time required to develop the associated infrastructure needed for hardware design verification.
Because many devices under test require extensive verification to ensure that such devices operate at their optimum potential, it is desirable, among other things, to develop a more unified description to synthesize a test environment in order to, for example, level the amount of time and work required for both RTL design and design verification.